Гостевой пост нашего партнера, IaaS-провайдера - компании ИТ-ГРАД. Технология vSAN является одним из элементов гиперконвергентной системы от VMware, которую активно используют облачные провайдеры для создания отказоустойчивой, гибкой и масштабируемой услуги по аренде виртуальной инфраструктуры (IaaS). Но прежде чем приступить к обсуждению данной технологии...

В конце прошлого года мы писали о новых возможностях VMware vCenter в составе обновленной платформы виртуализации VMware vSphere 6.7 Update 1. Среди прочих интересных фичей, vCenter 6.7 U1 получил функцию Health Сhecks, которая позволяет обрабатывать данные телеметрии виртуальной инфраструктуры и на основе экспертных алгоритмов вырабатывать рекомендации по ее улучшению. Например, если у вас одна сеть Management network, вам могут порекомендовать ее задублировать.

Вчера мы писали об общем устройстве механизма vSphere Health. Давайте теперь детально посмотрим, как именно это работает. Сделано это чем-то похоже на службы vSAN Health Services, но здесь больше проактивной составляющей (то есть рекомендации генерируются постепенно и еще до возникновения реальных проблем).

Для просмотра основных хэлсчеков сервера vCenter, нужно в vSphere Client пойти на вкладку Monitor и выбрать там раздел Health:

Чтобы эти фичи функционировали корректно, нужно чтобы у вас была включена настройка Customer experience improvement program (CEIP). Если вы не включили ее во время установки vCenter, то вы всегда можете сделать это в разделе Administration клиента vSphere Client:

Надо отметить, что vCenter Health Сhecks не только оповещает о проблемах виртуальной инфраструктуры, но и в некоторых случаях предоставляет ссылки на статьи базы знаний VMware KB, которые могут помочь найти решения.

Если вы нажмете на какой-нибудь из ворнингов, например, "Disk space check for VMware vCenter Server Appliance", то увидите две группы параметров на вкладках "Details" и "Info":

На вкладке Details отображены численные значения и/или объекты виртуальной инфраструктуры, имеющие отношение к предупреждению, а вот вкладка Info разъясняет его суть и дает рекомендации по его устранению. Если же в правом верхнем углу появился значок "Ask VMware", значит для данного предупреждения есть ссылка на статью базы знаний VMware KB, которая может помочь:

Например, здесь на двух из трех хостов ESXi установлена не последняя версия драйвера bnx2x (адаптер Broadcom NetXtreme II 10Gb):

На вкладке Info объясняется, что хосты с такой версией драйвера этого устройства могут вывалиться в "розовый экран":

Если нажмем "Ask VMware", то в новой вкладке откроется статья KB, описывающая проблемы данной версии драйвера и пути их решения:

Если вы сделали изменения конфигурации согласно рекомендациям, вы можете нажать кнопку RETEST в правом верхнем углу, чтобы увидеть только актуальные предупреждения:

Совсем недавно мы писали о книге по управлению инфраструктурой отказоустойчивых хранилищ с помощью сценариев - VMware PowerCLI Cookbook for vSAN, но оказалось, что есть еще одна книга, которая посвящена управлению средой vSAN. В документе-книге Operationalizing VMware vSAN, которая также занимает 88 страниц и вышла под эгидой VMware Press, рассказывается обо всех аспектах процесса интеграции vSAN в структуру организации после его внедрения - начиная от структурирования так называемых "day 2 operations" (ежедневная эксплуатация) и заканчивая процессами управления командой и разграничением ролей.

Предисловие к книге написал главный технолог VMware - Дункан Эппинг. Книга покрывает следующие аспекты эксплуатации vSAN:

• Почему важно наладить процессы ежедневных операций и формализовать их.
• Как измерять результат от интеграции vSAN в бизнес компании.
• Какие роли выделить под эксплуатацию инфраструктуры, как разграничить ответственность, какие сертификации кому нужно получить, и как люди должны между собой взаимодействовать.
• Рекомендации по выполнению ежедневных действий.
• Эффективное использование ресурсов, отслеживание производительности и текущего состояния компонентов инфраструктуры.
• Утилиты для мониторинга среды и решения проблем.

Если вы уже внедрили vSAN и не уверены, что все делаете правильно (а особенно если уверены), то обязательно хотя бы пролистайте эту книжку.

На сайте проекта VMware Labs появилось обновление полезной штуки для администраторов больших виртуальных инфраструктур - PowerCLI Preview for NSX-T. Напомним, что мы писали об этом решении вот тут. Оно предоставляет интерфейс PowerCLI/PowerShell к управлению решением для сетевой виртуализации NSX-T с помощью сценариев. Кстати, пользуясь случаем, рекомендуем вам статью нашего автора Романа Гельмана "Как управлять ролями NSX-менеджера при помощи PowerNSX".

Надо отметить, что это все еще Community Preview версия пакета команд, которая скоро будет добавлена в состав экосистемы PowerCLI, но на данный момент ее рекомендуется использовать только в тестовых целях.

Кстати, авторы отмечают, что получение дочернего объекта на основе всего родительского пока не работает, вместо этого рекомендуют использовать ID родителя (например, для команды Get-FirewallRule нужно использовать -SectionId и указать родительскую секцию вместо передачи родителя целиком в параметр -FirewallSection).

Для работы необходим PowerCLI 10.0.0 или более поздней версии.

Некоторые из вас, возможно, слышали об утилите vCheck for Horizon (vCheck-HorizonView), которая позволяет вам на регулярной основе готовить отчеты о текущем состоянии инфраструктуры виртуальных ПК VMware Horizon View. Этот проект базируется на утилите vCheck для VMware vSphere, которая развивается уже почти 7 лет.

В новой версии vCheck for Horizon появились следующие новые возможности:

1. Проверки состояния инфраструктуры ферм RDS:

2. Проверки состояния домена Active Directory:

3. Вызов vCenter API был разделен на 3 части - состояние сервиса vCenter, статус хостов ESXi и состояния подключенных датасторов:

4. Также была добавлена проверка работоспособности механизмов saml и truesso.

Скачать vCheck for Horizon можно по этой ссылке, а пример итогового отчета в формате HTML можно посмотреть вот тут.

В конце января компания Veeam, известная своим лучшим решением для резервного копирования виртуальных машин Veeam Backup and Replication (о последней версии мы писали вот тут), провела ренейминг и коррекцию позиционирования своих бесплатных продуктов.

Теперь все бесплатное называется Community Edition, при этом продукты с этим неймингом будут предоставлять больше возможностей, чем их Free Edition предшественники.

Соответственно, вот какие продукты выпускаются в бесплатном издании Community Edition:

1. Veeam Backup for Microsoft Office 365 Community Edition.

Ограничения бесплатной версии:

• Максимальное число пользователей Exchange: 10.
• Максимальное число пользователей OneDrive for business: 10.
• Максимальный объем защищаемых данных SharePoint: 1 ТБ.
• Поддержка вида Best effort.

2. Veeam Backup & Replication Community Edition.

Ограничения бесплатной версии:

• Доступны все функции издания Standard.
• Резервное копирование ограничено 10 объектами (физические или виртуальные машины).

Вот какие возможности предоставляет Veeam B&R Community Edition по сравнению с коммерческими версиями:

3. Veeam ONE Community Edition.

Ограничения бесплатной версии (их стало меньше, чем в прошлой бесплатной версии):

• Только один экземпляр Veeam B&R (платный или community edition) может быть добавлен.
• Нет возможностей Application level monitoring.
• Нет функции email customization.
• Отсутствует часть функционала отчетности.
• Некоторые прочие ограничения.

Veeam ONE еще в процессе ребрендинга, поэтому называется пока Free Edition, скоро это поменяется.

Недавно компания VMware объявила о выпуске бета-версии сервиса VMware Automated Virtual Assistant (AVA) - виртуального помощника, который может вам подсобить с поиском документации о продуктах VMware. Этот помощник предоставляется в виде чат-бота, который можно использовать посредством языка естественных запросов NLP (natural language processing). Он агрегирует знания из документации по vSphere, Horizon, vSAN и всем прочим продуктам, а также имеет ответы на соответствующие FAQs, которые есть по практически всем решениям VMware.

Например, вот таким образом можно спросить о документации, касающейся производительности виртуальных процессоров машин (vCPU) на платформе VMware vSphere 6.5:

Для активации помощника VMware AVA нужно просто зайти на сайт VMware Docs и вызвать всплывающее окно с любой страницы.

Пока AVA находится в режиме Training Mode - это означает, что движок еще проходит стадию обучения, и вы можете помочь ему корректно отвечать на вопросы своей обратной связью (для этого предусмотрен соответствующий функционал - например, пометить, какой из предложенных вариантов оказался лучшим). Это позволит объединить похожие запросы и выдавать более релевантные результаты в будущем.

Помимо запросов к документации и часто задаваемым вопросам, вы можете поделиться с AVA своей проблемой (конечно же, касательно виртуальной инфраструктуры:) - и она попытается найти решение.

Кстати, обратите внимание, что на картинке выше показано, что AVA помнит контекст беседы. Она запомнила, что речь будет идти о платформе vSphere версии 6.5, и все дальнейшие вопросы она будет воспринимать как относящиеся именно к этому продукту.

Пока Automated Virtual Assistant доступен только на английском языке, но обещают и поддержку других языков. Однако, как мы знаем, VMware не очень жалует русский, поэтому не стоит ждать его поддержки, по крайней мере, в ближайшем будущем. А так AVA - штука весьма интересная.

На сайте проекта VMware Labs появилась интересная и полезная некоторым администраторам vSphere штука - USB Network Native Driver for ESXi. Это нативный драйвер для сетевых адаптеров серверов, которые подключаются через USB-порт.

Такой адаптер можно использовать, когда вам необходимо, например, подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. В каких-то еще случаях подключение такого адаптера может помочь, чтобы получить еще одно сетевое соединение без необходимости перезагружать сервер (и так же просто отключить его).

На данный момент драйвер поддерживает 3 самых популярных чипсета на рынке:

• ASIX USB 2.0 gigabit network ASIX88178a
• ASIX USB 3.0 gigabit network ASIX88179
• Realtek USB 3.0 gigabit network RTL8153

А вот, собственно, и сами поддерживаемые адаптеры:

Надо отметить, что это сравнительно недорогие устройства, которые может позволить себе каждый администратор платформы vSphere.

Установка драйвера производится одной командой:

esxcli software vib install -d /path/to/the offline bundle

Затем нужно будет перезагрузить хост VMware ESXi, после чего устройство USB NIC будет автоматически смонтировано как, например, vusb0. Но чтобы приаттачить такой NIC к виртуальному коммутатору vSwitch, придется добавить в /etc/rc.local.d/local.sh такой скрипт:

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

  count=0

  while [[ $count -lt 20 && "${vusb0_status}" != "Up" ]] ]

  do

sleep 10

count=$(( $count + 1 ))

vusb0_status=$(esxcli network nic get -n vusb0 | grep 'Link Status' | awk '{print $NF}')

done

if [ "${vusb0_status}" = "Up" ]; then

  esxcfg-vswitch -L vusb0 vSwitch0

  esxcfg-vswitch -M vusb0 -p "Management Network" vSwitch0

  esxcfg-vswitch -M vusb0 -p "VM Network" vSwitch0

  fi

Драйвер работает с VMware vSphere 6.5 и 6.7. Скачать его можно по этой ссылке.

Пару недель назад мы писали о большом анонсе Veeam, где было рассказано о новых версиях и возможностях следующих продуктов:

• Обновление Veeam Availability Suite 9.5 Update 4 и Veeam Backup and Replication 9.5 Update 4 в его составе.
• Новое решение Veeam Availability for AWS.
• Обновление решения Veeam Availability Console v3.

О новых возможностях Veeam Backup and Replication 9.5 Update 4 мы уже детально писали вот тут, а сегодня расскажем о новых фичах последних двух решений.

1. Veeam Availability for AWS.

Этот продукт позволяет защитить ваши виртуальные машины в публичном облаке Amazon от случайного удаления, вредоносной активности или различного рода сбоев за счет резервного копирования и восстановления инстансов EC2. Это решение было анонсировано еще на VeeamON 2017, но только сейчас вышла его финальная версия.

Оно комбинирует в себе возможности купленной Veeam компании N2WS cloud-native backup and recovery для рабочих нагрузок AWS с возможностью консолидации резервных копий в центральном репозитории Veeam.

Продукт предоставляет следующие возможности:

• Безагентная защита виртуальных машин на AWS средствами снапшотов (для целей мгновенного восстановления). Делается это на базе сервиса Amazon EBS.
• Возможность долговременного хранения бэкапов в облаке Amazon S3 или онпремизной инфраструктуре компании. Это экономит затраты на хранение до 40%.
• Быстрое восстановление из резервных копий в облаке, включая такие технологии как instant recovery, восстановление напрямую в онпремизный датацентр или в другое облако. Возможность восстановления в другой аккаунт.
• Расширенный поиск по инфраструктуре хранения бэкапов.
• Восстановление баз данных на определенный момент времени, а также послеаварийное восстановление Amazon RDS, Redshift и DynamoDB в другой регион AWS или аккаунт другого пользователя.

Узнать больше о решении Veeam Availability for AWS можно на этой странице.

2. Veeam Availability Console v3.

Это уже третья версия консоли Availability Console для сервис-провайдеров (напомним, что сама по себе она бесплатна). О ней мы детально писали вот тут. Это комплекс интегрированных средств для сервис-провайдеров и больших компаний, которые позволяют организовать инфраструктуру BaaS (Backup-as-a-Service) для гибридной среды предприятия (внутренние инфраструктуры + облачные).

Давайте посмотрим на новые возможности сервис-провайдеров, которые приходят вместе с Veeam Backup and Replication 9.5 Update 4:

• Интеграция для пользователей Veeam Cloud Connect Replication и VMware vCloud Director, что позволяет построить единую платформу управления облачной платформы и предлагать комплексное DRaaS-решение в рамках единого пространства сети, оборудования и средств самообслуживания.
• Cloud Gateway Pools для Veeam Cloud Connect Backup and Replication - теперь с помощью этого функционала можно развернуть внутренние пулы IP-адресов клиентов, которые подключаются к вашей сети через MPLS или VPLS соединения. Это улучшает изоляцию между клиентами и упрощает развертывание больших инфраструктур в облаках.
• Расширенная поддержка резервного копирования на базе агентов. Теперь средства Veeam Agents поддерживают несколько одновременных задач резервного копирования, что позволяет еще более гибко управлять ими со стороны облачного провайдера.

Также теперь для сервис-провайдеров доступны следующие новые возможности решений для резервного копирования и мониторинга виртуальных сред Veeam:

Более подробно о Veeam Availability Console можно узнать на этой странице.

На сайте VMware появился полезнейший технический документ, даже практически книга об использовании фреймворка PowerCLI для инфраструктуры отказоустойчивых кластеров хранилищ - VMware PowerCLI Cookbook for vSAN.

На 88 страницах авторы (Jase McCarty и его коллеги), работавшие с PowerCLI/PowerShell для управления инфраструктурой vSAN более 4 лет, рассказывают обо всех аспектах управления хранилищами с помощью сценариев.

Книга дает "рецепты" в следующих сферах:

• Конфигурация решения vSAN
• Операционные ежедневные задачи
• Функции отчетности о текущем состоянии среды

В книге приведено большое количество примеров, причем авторы сначала показывают, как задачу можно выполнить в графическом интерфейсе, а затем разбирают кейс по автоматизации данных действий с помощью PowerCLI.

Кстати, это только первый релиз книги (1.0), со временем она будет дополняться. Скачать VMware PowerCLI Cookbook for vSAN можно по этой ссылке.

Те из вас, кто разрабатывает, дорабатывает и использует сценарии VMware PowerCLI, знает, что время от времени требуется использовать модуль какой-то конкретной версии, который идет в составе PowerCLI определенной версии. Это может быть из-за бага в новом пакете или несовместимости старых скриптов с новыми модулями.

Если вы посмотрите на свойства пакета VMware PowerCLI на сайте PowerShell Gallery, то увидите соответствующие версии входящих в него модулей:

Если вам нужно скачать нужный пакет из PowerShell Gallery, сделать это просто - там есть кнопка Manual Download:

Но есть и возможность напрямую установить модуль из галереи, используя команду:

Install-Module -Name VMware.PowerCLI

Но это команда установит только последнюю версию модуля, а на блоге VMware появилась интересная функция Save-PowerCLI, которая позволяет указать в параметре -RequiredVersion нужную версию и скачать ее с последующей установкой:

Собственно, сам исходник функции Save-PowerCLI:

Больше пяти лет назад мы писали про проект vCenter Server Simulator 2.0 (VCSIM), который позволял протестировать основные интерфейсы VMware vCenter без необходимости его реального развертывания (а значит и без лицензии). Проблема в том, что он был выпущен для VMware vSphere и vCenter версий 5.5 и с тех пор не обновлялся.

Зато есть аналог старому VCSIM - новый проект govcsim, написанный на языке Go (Golang). Он точно так же умеет предоставлять API-ответы на вызовы к vCenter Server и ESXi.

Несмотря на то, что этот симулятор написан на Go, он позволяет вам работать с vCenter посредством любого языка и интерфейса, умеющего общаться через API (в том числе, PowerShell). То есть, вы можете соединиться через PowerCLI к VCSIM Docker Container и работать с ним как с сервером vCenter.

Сам контейнер nimmis/vcsim можно скачать отсюда. Pull-команда для него:

docker pull nimmis/vcsim

Далее можно выполнить вот такой сценарий (взято у Brian Bunke):

docker run --rm -d -p 443:443/tcp nimmis/vcsim:latest

If ($IsMacOS -or $IsLinux) {

$Server = 'localhost'

} Else {

$Server = (Get-NetIPAddress -InterfaceAlias *docker* -AddressFamily IPv4).IPAddress

}
If ($PSVersionTable.PSVersion.Major -ge 6) {

Test-Connection $Server -TCPPort 443

}
Connect-VIServer -Server $Server -Port 443 -User u -Password p

# Did it work?

Get-VM

# Or Get-VMHost, or Get-Datastore, etc.

Этот код делает следующее:

• Запускает docker-контейнер VCSIM локально (если у вас его нет, то он будет загружен).
• На Windows-системе получает IP-адрес адаптера DockerNAT.
• После запуска контейнера тестирует, что порт 443 отвечает.
• Использует модуль VMware.PowerCLI интерфейса PowerShell для соединения с vCenter Simulator.

Симулятор на данный момент поддерживает не все множество API-методов (смотрите документацию). Вот так, например, можно вывести список всех поддерживаемых методов и типов:

$About = Invoke-RestMethod -Uri "https://$($Server):443/about" -Method Get

$About.Methods

$About.Types

Например, вы можете использовать PowerOffVM_Task, PowerOnMultiVM_Task и PowerOnVM_Task. Из PowerCLI попробуйте также протестировать командлеты Stop-VM и Start-VM. Ну а дальше изучайте документацию к библиотеке govmomi.

Во время прошедшего летом прошлого года VMworld 2018 компания VMware представила много интересных новостей на тему будущей функциональности продукта для создания отказоустойчивых хранилищ VMware vSAN. Например, мы писали о технологии Native Data Protection (это часть 1 этого цикла статей), а сегодня поговорим о сервисах хранения.

Диски First Class Disk (FCD)

Для vSAN уже есть поддержка так называемых дисков First Class Disk (FCD), они же называются Improved Virtual Disk (IVDs) или Managed Virtual Disk. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования.

К таким относятся, например, тома VMware App Volumes, на которых размещаются приложения, и которые присоединяются к виртуальным машинам во время работы пользователя с основной машиной. Также к таким дискам относятся хранилища для cloud native приложений и приложений в контейнерах, например, работающих через Docker Plugin и драйвер Kubernetes (он называется vSphere Cloud Provider) для создания постоянных (persistent) томов контейнеров Docker. Этим всем занимается опенсорсный проект Project Hatchway от VMware.

Работать с такими дисками очень неудобно - для них приходится создавать отдельную виртуальную машину к которой цепляется этот диск, а потом, по завершении какого-либо процесса, отсоединяется, и машина уничтожается. Так, например, работает средство для резервного копирования App Volumes Backup Utility, о котором мы писали вот тут. При бэкапе этих дисков создается временная Backup VM:

Второй пример - инфраструктура vSphere Integrated OpenStack (VIO), где для того, чтобы включить хранилище Cinder (OpenStack Block Storage) для потребления дисковой емкости VMDK-файлов, нужно создавать вспомогательные Shadow VM для каждого тома Cinder, к которому цепляется VMDK-диск.

Все это неудобно, поэтому и придумали формат дисков First Class Disk (FCD), которому не требуются временные виртуальные машины и которые реализуют сервисы, необходимые приложениям или другим сервисам. Например, бэкап таких дисков можно делать без создания вспомогательной ВМ.

Информация о дисках FCD хранится в каталоге базы данных vCenter. Она содержит глобальные уникальные идентификаторы UUID и имена дисков. UUID позволяет переместить диск в любое место без конфликтов.

Впервые API для работы с FCD появился в VMware vSphere 6.5, например, вот хороший пост от Вильяма Лама об этом. Но в этом релизе было ограничение на резервное копирование FCD-дисков, которые не присоединены к ВМ (в качестве workaround приходилось все же использовать Dummy VM).

В vSphere 6.7 это ограничение было снято, но остались еще некоторые требования - FCD нужно было восстанавливать с тем же UUID и на тот же датастор, откуда он был взят. Также еще одним ограничением была невозможность API отслеживать блоки, изменившиеся с момента последней резервной копии, то есть невозможность инкрементального резервного копирования (подробнее здесь).

Ну а в vSphere 6.7 Update 1 была анонсирована ограниченная поддержка FCD для vSAN. Пока поддержка предоставляется еще с ограничениями для служб health service и capacity monitoring. Однако при этом пользователи Kubernetes могут использовать диски FCD на хранилищах vSAN для персистентных хранилищ контейнеров, и в то же самое время тома vSAN могут использоваться для виртуальных машин:

Подписаться на бету следующей версии продукта VMware vSAN можно по этой ссылке.

В следующей статье мы расскажем про Cloud Native Storage (CNS) и vSAN File Services.

Давайте для начала разберёмся с терминологией. Что такое роли NSX-менеджера? Роли NSX-менеджера позволяют управлять правами доступа к объектам NSX с помощью присвоения той или иной роли отдельному пользователю или группе. В UI эти настройки находятся в Networking & Security -> System -> Users and Domains.

Как пишет Kalle в своем блоге, если вы используете платформу VMware Workstation в серверной ОС Windows Server 2019, то виртуальные машины у вас могут валиться с ошибками, если для дисков, на которых они размещены, включена дедупликация. При этом диски могут быть как NTFS, так и ReFS, а в журнале событий у процессов vmware-vmx.exe можно найти следующее:

Faulting application name: vmware-vmx.exe, version: 15.0.2.40550, time stamp: 0x5bf5251a

Faulting module name: vmware-vmx.exe, version: 15.0.2.40550, time stamp: 0x5bf5251a

Exception code: 0xc0000005

Fault offset: 0x000000000049db36

Faulting process id: 0x2a9c

Faulting application start time: 0x01d48a67966e2ea4

Faulting application path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe

Faulting module path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe

Report Id: 7dd5aa8c-2f51-471d-b9e4-e04d0caf099b

Faulting package full name: 

Faulting package-relative application ID:

При этом на Windows Server 2012 R2 при точно таких же настройках дедупликации все работает вполне нормально:

Он также пробовал различные настройки дедупликации на Windows Server 2019 (General purpose file server и Virtualized Backup Server), но машины на VMware Workstation 15 все равно валятся с ошибкой случайным образом.

Недавно компания VMware объявила о выпуске обновленной версии решения VMware PKS 1.3 (Pivotal Container Service), предназначенного для управления гибридными средами Kubernetes в онпремизных и публичных облаках. Напомним, что об анонсах на VMworld Europe 2018, касающихся этого продукта, мы писали вот тут.

Тогда было объявлено о покупке компании Heptio, которую основали создатели Kubernetes. Она предоставляет набор продуктов и профессиональных сервисов для управления контейнерами Kubernetes в онпремизных, публичных и гибридных облачных средах. Помимо управления контейнерами, решения Heptio предоставляют такие сервисы, как оркестрация приложений, поддержка жизненного цикла (развертывание, хэлсчек) и обеспечение доступности (снапшоты, резервное копирование).

Теперь кое-что из этого было добавлено в VMware PKS, который стал поддерживать облачную среду Microsoft Azure. Кроме того, в продукте были улучшены функции контроля сетевого взаимодействия, безопасности и управления.

Давайте посмотрим, что нового появилось в PKS 1.3:

1. Поддержка публичного облака Microsoft Azure.

Ранее PKS поддерживал облачные среды VMware vSphere, Google Cloud Platform и Amazon EC2. Теперь он работает и в Azure:

PKS позволяет самостоятельно развернуть кластеры Kubernetes в облаке (или сразу нескольких облаках) и получить все инструменты для ежедневной эксплуатации решения.

2. Улучшения гибкости и средств настройки сетевой среды и инфраструктуры безопасности.

Теперь сетевые профили кластеров, которые появились еще в версии 1.2, получили еще больше параметров настройки.

• Поддержка нескольких Tier 0 маршрутизаторов для лучшей изоляции контейнерных сред. Один экземпляр VMware NSX-T может обслуживать несколько Tier 0 маршрутизаторов, что дает не только функции безопасности, но и возможности настройки отдельных диапазонов IP для каждого роутера и его клиентов.

• Маршрутизируемые IP-адреса, назначаемые группам узлов (Pods), что позволяет обеспечить их прозрачную коммуникацию с внешним миром (а также достучаться к ним из внешнего мира). Если необходимо, можно использовать и NAT-схему. Более подробно об этом написано здесь.
• Для групп Pods можно перекрыть глобальные настройки диапазона IP-адресов и размера подсети, задав их для отдельных групп. Это дает больше гибкости в плане использования глобального диапазона адресов.
• Поддержка больших (large) балансировщиков в дополнение к small и medium. Это увеличивает число предоставляемых сервисов, число групп на бэкенде в расчете на сервис, а также количество транзакций в секунду на сервис.
• Лучшая изоляция окружений за счет размещения нескольких VMware PKS Control Planes в рамках одного экземпляра NSX-T. Каждый управляющий объект VMware PKS control plane можно разместить на выделенном маршрутизаторе NSX-T Tier 0. Это позволяет лучше разделить окружения и, например, обновлять тестовую среду независимо от производственной, работая с двумя экземплярами PKS.

3. Улучшенные операции управления.

Здесь произошли следующие улучшения:

• Средства резервного копирования и восстановления кластеров Kubernetes. Теперь, помимо бэкапа средств управления Control Planes, появилась возможность бэкапа и stateless-нагрузок в контейнерах средствами тулсета BOSH Backup and Restore (BBR).
• Возможность проведения смоук-тестов. С помощью PKS 1.3 возможно создание специализированной тестовой среды, которую можно использовать для проверки апгрейда кластера, чтобы убедиться, что на производственной среде апгрейд пройдет нормально. После окончания теста тестовый кластер удаляется, после чего можно спокойно апгрейдить продакшен.

4. Поддержка Kubernetes 1.12 и другие возможности.

VMware PKS 1.3 поддерживает все стабильные физи релиза Kubernetes 1.12. Со стороны VMware они прошли тесты Cloud Native Computing Foundation (CNCF) Kubernetes conformance tests.

Также в рамках одной группы контейнеры могут иметь общие тома. Это может пригодиться, например, для общей базы данных нескольких приложений в разных контейнерах.

Кроме того, компоненты NSX-T и другие управляющие элементы, такие как VMware vCenter, можно разместить за HTTP proxy, требующим аутентификации. Ну и VMware PKS 1.3 включает решение Harbor 1.7 с новыми возможностями, такими как управление диаграммами Helm, улучшенная поддержка LDAP, репликация образов и миграции базы данных.

Более подробно о VMware PKS 1.3 написано по этой ссылке. Также больше подробностей об обновлении можно узнать тут, а вот тут можно пройти практическую лабораторную работу по решению PKS.

Больше 7 лет назад мы писали о резервном копировании конфигурации решения для виртуализации настольных ПК предприятия VMware View. С тех пор многое изменилось, поэтому пора актуализировать процедуру, которая стала с тех пор несколько проще (но не кардинально).

Чтобы создать консистентную резервную копию конфигурации инфраструктуры VMware Horizon, нужно в одно время и в следующем порядке создать бэкап следующих компонентов, составляющих конфигурацию View Manager:

• База данных View Manager ADAM (база Connection Server)
• База данных View Composer
• База данных VMware vCenter

Соответственно и восстанавливать все эти компоненты нужно тоже в одно время, чтобы у вас вся инфраструктура оказалась консистентной и пригодной к использованию.

1. Резервное копирование и восстановление View Manager: база данных Connection Server.

Резервное копирование конфигурации Connection Server

Сначала нужно убедиться, что в данный момент нет активных операций create, recompose или delete. Также надо остановить развертывание новых виртуальных машин, чтобы избежать проблем, связанных с процессами синхронизации. Для этого во View Administrator идем в View Configuration > Servers. Там выбираем сервер vCenter и в разделе Settings нажимаем Disable provisioning (не забудьте это включить назад после окончания резервного копирования).

В графическом интерфейсе View Manager резервную копию базы данных можно сделать в разделе View Configuration > Servers, где на вкладке Connection Servers нужно выбрать любой сервер реплицируемой группы и нажать кнопку "Backup Now...". Это сохранит базы данных серверов Connection Server и Composer.

Помните, что даже если у вас несколько серверов Connection Server в одной реплицируемой группе, то делать регулярные бэкапы все равно нужно. Если у вас испортится конфигурация на одном из серверов - она будет отреплицирована на все серверы группы.

Все бэкапы будут по умолчанию сохраняться по следующему пути:

C:\ProgramData\VMware\VDM\backups

Если нажать "Edit..." для настроек сервера Connection Server, то можно увидеть настройки регулярного запланированного резервного копирования с опциями периодичности (от 1 часа до 2 недель), политики хранения и возможность задания пароля для выходного файла.

Также экспорт базы данных View Connection Server LDAP можно сделать с помощью консольной утилиты vdmexport, которая находится вот тут:

C:\Program Files\VMware\VMware View\Server\tools\bin\vdmexport.exe

Файлы будут экспортированы в формат LDAP data interchange format (LDIF). Возможно 3 варианта использования утилиты:

• vdmexport -f configuration_data.LDF (по умолчанию этот файл зашифрован паролем, см. скриншот выше)
• vdmexport -f configuration_data.LDF -v (экспорт данных в формате plain text)
• vdmexport -f configuration_data.LDF -c (cleansed, экспорт данных в открытом текстовом формате, но без чувствительной информации - пароли и т.п.)

Бэкап конфигурации в формате cleansed делать не рекомендуется, так как при его восстановлении вы лишитесь критичной части информации в восстановленной конфигурации.

Делаем бэкап базы Connection Server (эта команда не делает бэкап базы Composer):

vdmexport -f C:\conn_server_backups\Backup_1.LDF

Восстановление конфигурации Connection Server

Перед восстановлением конфигурации серверов Connection Server нужно убедиться, что у вас есть все необходимые файлы для восстановления конфигурации и сделать следующее:

• Остановить службы VMware Horizon Security Server на серверах Security Server.
• Остановить службы View Composer на серверах Composer/vCenter.
• Удалить на серверах компоненты VMware Horizon Connection Server и AD LDS Instance VMwareVDMDS.
• Установить один экземпляр Connection Server и остановить там службу VMware Horizon Connection Server.

Восстановление базы View Connection Server выглядит следующим образом:

1. Расшифровываем файл бэкапа (если вы делали бэкап как plain text, этого делать не нужно):

vdmimport -d -p mypassword -f C:\conn_server_backups\Backup_1.LDF > Decrypted_Backup_1.LDF

2. Импортируем конфигурацию View Manager (Connection Server):

vdmimport -f Decrypted_Backup_1.LDF

3. После этого можно удалить только компонент VMware Horizon Connection Server и переустановить его для новой конфигурации базы данных. Далее в Horizon Administrator нужно убедиться, что настройки восстановлены.

4. Затем нужно запустить серверы View Composer, а также установить и настроить все реплики серверов Connection Server.

5. Последним шагом надо запустить все экземпляры Security Servers.

Если после восстановления серверов Connection Servers серверы Security Servers окажутся в неконсистентном состоянии, то последние придется переустановить.

Также все эти шаги можно посмотреть в видео ниже:

Ну и об этом процессе подробно написано в KB 1008046, а также в документе Horizon 7 Administration Guide.

2. Резервное копирование и восстановление View Manager: база данных Composer.

Резервное копирование конфигурации Composer

Перед резервным копированием восстановлением View Composer нужно убедиться, что у вас нет активных операций recompose/refresh и остановить его службы (Start > Administrative Tools > Services, далее остановить службу VMware View Composer).

Файлы бэкапов View Composer имеют расширение *.svi и по умолчанию лежат в той же папке, что и для Connection Server:

C:\ProgramData\VMware\VDM\backups

Выглядят они подобным образом:

Backup-YearMonthDayCount-vCenter Server Name_Domain_Name.svi

Для бэкапа базы View Composer нужно выполнить следующую команду (поробнее - тут, утилита sviconfig.exe находится в папке установки Composer):

sviconfig -operation=exportdata -DsnName=LinkedClone -username=Admin -password=Pass -outputfilepath="C:\Program Files\VMware\VMware View Composer\backup_1.svi"

Параметр DsnName - это DSN-имя, которое используется для соединения с базой данных.

Операция sviconfig exportdata возвращает один из следующих кодов:

После создания резервной копии запустите Composer.

Восстановление конфигурации Composer

Для восстановления базы View Composer нужно выполнить следующую команду (поробнее - тут):

sviconfig -operation=restoredata -DsnName=LinkedClone -username=Admin -password=Pass -backupfilepath="C:\Program Files\VMware\VMware View Composer\backup_1.svi"

Операция sviconfig restoredata возвращает один из следующих кодов:

После этого можно запустить службу View Composer. Надо понимать, что после восстановления базы View Composer могут быть некоторые расхождения с конфигурацией View Connection Server, которые надо будет устранять вручную.

3. Резервное копирование и восстановление БД vCenter Server.

Для резервного копирования и восстановления баз данных виртуального модуля VMware vCenter Server Appliance (vCSA) и vCenter Server for Windows используйте инструкцию, приведенную в KB 2091961.

В видео ниже вы можете посмотреть как делать бэкап и восстановление БД vCenter для vCSA:

А вот так делается резервная копия и восстанавливается БД vCenter Server for Windows (Embedded database):

Помните, что при восстановлении конфигурации Connection Server и Composer она должна соответствовать конфигурации виртуальной инфраструктуры на сервере vCenter (имена виртуальных машин, объектов и т.п.), поэтому не пренебрегайте процессом восстановления конфигурации vCenter.

Вчера на мероприятии по запуску новых продуктов и решений компания Veeam представила сразу 3 важных обновления:

• Обновление Veeam Availability Suite 9.5 Update 4 и Veeam Backup and Replication 9.5 Update 4 в его составе.
• Новое решение Veeam Availability for AWS.
• Обновление решения Veeam Availability Console v3.

Обязательно посмотрите большой анонс этих продуктов, в котором принял участие основатель компании Ратмир Тимашев:

В этой статье мы остановимся только на лидирующем в отрасли продукте Veeam Backup and Replication 9.5 Update 4, который уже сейчас доступен для скачивания:

Давайте посмотрим, какие интересные новые возможности появились в Veeam B&R 9.5 Update 4:

0. Поддержка vSphere 6.7 Update1.

Долгожданная поддержка последней версии платформы vSphere 6.7 Update 1, а также решений vCloud Director 9.5 и платформы Windows Server 2019 (включая Hyper-V 2019, Active Directory 2019, Exchange 2019 и SharePoint 2019).

1. Veeam Cloud Tier.

В новом релизе появилась нативная интеграция с облачными объектными хранилищами, которые можно использовать для долговременного хранения бэкапов в рамках концепции Scale-out Backup Repository. При этом оперативные резервные копии можно оставить на ярусе Performance Tier:

Теперь бэкапы можно передавать в облачное хранилище Amazon S3, Azure Blob Storage, IBM Cloud Object Storage, любое S3-совместимое хранилище или в другой датацентр для целей архивного хранения и/или катастрофоустойчивости.

Кстати, эта схема не требует наличия каких-то виртуальных модулей от вендоров облачных платформ, что позволяет не завязывать эту схему на одно конкретное облако.

2. Veeam Cloud Mobility.

Эти возможности позволяют восстановить резервные копии виртуальных машин, хранящиеся в репозиториях Veeam (в том числе, от Veeam Agent для Windows и Linux), на любую из облачных платформ в производственную среду. На данный момент поддерживаются платформы AWS, Azure и Azure Stack, а также любые онпремизные бэкапы:

Для облака AWS EC2 происходит автоматическая конверсия UEFI на BIOS для виртуальных машин.

3. Veeam DataLabs.

Данные функции Veeam B&R позволяют тестировать различные рабочие нагрузки, валидировать апдейты и патчи, проверять на наличие уязвимостей и соответствие политикам предприятия, а также убеждаться в общей восстановимости резервных копий.

Здесь Veeam B&R 9.5 Update 4 предоставляет следующие функции:

• On-Demand Sandbox - виртуальная песочница для тестирования восстановленных резервных копий.
• SureBackup и SureReplica - возможность удостовериться в работоспособности восстановления бэкапов и реплик.
• Staged Restore (об этой возможности мы писали вот тут) - позволяет уменьшить время на просмотр и отсеивание чувствительных данных и убрать персональную информацию при восстановлении резервной копии (в частности, об уволенных сотрудниках). Это позволяет соблюсти требования GDPR и не попасть на штраф.
• Secure Restore (об этой возможности мы писали вот тут) - возможность сканирования восстановленных резервных копий с помощью антивирусного программного обеспечения, чтобы устранить угрозы перед вводом восстановленных бэкапов в производственную среду.

4. Veeam Intelligent Diagnostics.

Эти возможности позволяют установить на серверы Veeam B&R агенты Veeam ONE, которые анализируют логи процесса бэкапа и самого решения для резервного копирования, что позволяет идентифицировать и решить проблемы самостоятельно, без обращения в техническую поддержку.

Сигнатуры с описанием известных проблем загружаются из базы знаний Veeam.

5. Прочие улучшения.

Полный список улучшений нового Veeam B&R приведен в документе What's New, а мы особенно отметим следующие:

• Портал самообслуживания для ролевой модели доступа vSphere RBAC на базе Enterprise Manager.
• Внешний репозиторий для N2WS.
• Улучшения бэкапа на ленточные носители.
• Плагин к Oracle RMAN.
• Плагин к SAP Hana Plugin.
• Улучшение продукта Veeam Explorer.

Скачать Veeam Backup and Replication 9.5 Update 4 можно по этой ссылке, Release Notes доступны тут.

На сайте проекта VMware Labs появился апдейт основного средства управления виртуальной инфраструктурой - VMware vSphere Client 4.0. Напомним, что, начиная с версии vSphere 6.7 Update 1, vSphere Client является официально поддерживаемым средством управления для всех рабочих процессов платформы vSphere. О последней версии vSphere Client 3.42 мы писали осенью прошлого года вот тут.

Теперь VMware в обновленной версии клиента исправила несколько ошибок, а также отключила поддержку старых версий VMware vSphere. Новый клиент работает, начиная с vSphere 6.5 и более поздними версиями. То есть, если у вас vSphere 6.0, то не обновляйте ваш клиент (тем более, что линка на загрузку прошлой версии уже нет), а используйте версию 3.42, которая реализует весь функционал.

Также надо помнить, что если вы используете vSphere 6.5, то у вас будет недоступен плагин к VMware vSphere Update Manager (VUM). Интересно, что в Changelog написано о том, что в клиенте есть некоторые New Features, но не написано, какие именно)

UPD. Новый клиент vSphere Client 4.0 предоставляет следующие новые возможности:

• Поддержка VMware vCenter 6.7, браузер просмотра файлов и папок стал работать заметно быстрее.
• Графический интерфейс ESX Agent Manager.
• Настройки MxN Convergence в разделе System Configuration
• Возможность импорта сертификатов и генерации запроса CSR.
• Функции Code Capture: кнопка записи может быть нажата между состояниями hidden и shown.
• Возможность удалить бандлы скриптов (Script Bundles) в механизме Autodeploy для vCenter 6.7.
• Возможность удалить Discovered hosts в механизме Autodeploy для vCenter 6.7.
• Экспорт данных о лицензиях в формате CSV для всех представлений, связанных с просмотром лицензий.
• Добавление и назначение лицензий в рамках одной операции.
• Настройка аутентификации на прокси-сервере для VC 6.5+ (раздел VC > Configure  > Settings > Authentication Proxy).

При обновлении клиента на версию vSphere Client 4.0 с 3.x вам нужно будет повторно подключить его к инфраструктуре vSphere и ввести учетные данные.

Скачать VMware vSphere Client 4.0 можно по этой ссылке.

В прошлом посте мы рассказывали о IOchain - цепочке прохождения пакетов через сетевой стек хоста VMware ESXi, а в этом остановимся на некоторых утилитах, работающих с этим стеком и помогающих решать различного рода сетевые проблемы.

Прежде всего, при решении проблем соединений на хосте ESXi нужно использовать следующие средства:

• Консольная утилита esxtop (представление network)
• ping / vmkping
• traceroute

Но если хочется углубиться дальше в сетевое взаимодействие на хосте, то тут могут оказаться полезными следующие утилиты:

• net-stats
• pktcap-uw
• nc
• iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

Далее нужно сопоставить вывод блока sys для нужного интерфейса и вывода команды:

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

• Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

• Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

• Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

• Ограничить захват заданным числом пакетов:

pktcap-uw -c 100

• Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

По умолчанию утилита работает на портах, которые запрещены фаерволом ESXi, поэтому во время работы с ней нужно его потушить (не забудьте потом его включить):

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.

Гостевой пост нашего спонсора - компании ИТ-ГРАД (теперь часть МТС), предоставляющей услуги виртуальной инфраструктуры VMware в аренду по модели IaaS.

В 1981 году на экраны вышел культовый фильм Джорджа Миллера с участием Мела Гибсона «Безумный Макс: Воин дороги». Этот фильм принес в английский  язык новый термин: «road warrior», которым стали называть сотрудников, чья работа требовала большого количества путешествий. Такие сотрудники должны были только время от времени приезжать в офис для выполнения административных задач вроде оформления отчета о расходах или получения информации о клиентах. По мере развития информационных и телекоммуникационных технологий сотрудникам уже не нужно было появляться в офисе – многие операции можно было выполнять дистанционно – сначала при помощи модема, затем, после развития Интернет – с помощью VPN-канала.

В наше время современные технологии позволяют выполнять офисную работу все большему количеству людей, не выходя из дома. По данным Eurostat, 35% предприятий в Европе в настоящее время предлагают своим сотрудникам возможность работать из дома.

Все более широкое использование дистанционных методов работы усложнило для организаций поиск оптимального баланса между безопасностью и удобством работы.  Дело в том, что все выгоды, связанные с дистанционной работой, могут быть потеряны из-за недостаточной защиты.

Согласно исследованию Ponemon Institute средняя стоимость ущерба, связанного с нарушением безопасности, возросла с 3,62 млн. долларов в 2017 г.  до 3,86 млн. долларов в 2018 г., то есть на 6,4 процента. Количество и сложность инцидентов, связанных с безопасностью, также возросли.

Как правило, серверы и компьютеры в офисе компании хорошо защищены при помощи программного и аппаратного обеспечения, и приложения, с которыми работают сотрудники компании, размещены внутри защищенного периметра.

Созданная внутренняя инфраструктура безопасности обслуживается не одним человеком, а целым департаментом, в котором каждый инженер занимается своим направлением. В классическом сценарии, все управление web-безопасностью сконцентрировано в головном офисе, и весть трафик настроен на прохождение через единый шлюз.

Проблемы возникают тогда...Читать статью далее->>

На сайте проекта VMware Labs появилось превью технологии PowerCLI for VMware Cloud on AWS, которая представляет собой расширение фреймворка PowerCLI на публичное облако от Amazon и VMware. Расширение поставляется как отдельный модуль PowerCLI (VMware.VimAutomation.VmcPreview), который интегрируется с остальными модулями.

Все команды модуля сгенерированы автоматически, в данный момент они находятся в разработке, поэтому могут обновляться и изменяться, что нужно учитывать при разработке сценариев. Всего в модуле присутствует 14 высокоуровневых командлетов, таких как Get-Organization или Get-Sddc. Давайте взглянем, как это примерно работает.

Для начала работы вам понадобится PowerCLI 11.0.0 или более старшей версии. Установить модуль можно автоматически из PowerShell Gallery с помощью команды:

Install-Module -Name VMware.VimAutomation.VmcPreview -RequiredVersion 1.0.0.11171858

После установки сначала аутентифицируемся с помощью токена, который можно найти в облачной консоли VMware Cloud on AWS Cloud в разделе Account:

Connect-Vmc -RefreshToken xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Далее получим информацию о нашей организации:

Get-Organization

С помощью Select-Object можно отфильтровать вывод по свойствам:

Get-Organization | Select-Object -Property Id, DisplayName

Также можно получить объект SDDC, используя Organization ID:

Далее с объектом SDDC можно работать как в привычной среде PowerCLI, например, получить AWS Region, какие зоны Availability Zones используются, информацию об NSX (например, Manager URL), а также vCenter URL:

Скачать VMware vCloud on AWS можно по этой ссылке.

На сайте проекта VMware Labs появилась новая утилита, которая может оказаться полезной пользователям решения Workspace ONE в крупной инфраструктуре. С помощью Workspace ONE Provisioning Tool можно развернуть приложения на тестовой виртуальной машине, чтобы убедиться в том, что их можно развертывать в производственной среде Dell Factory. Эта утилита имеет в себе часть функционала средства Workspace ONE Configuration Tool for Provisioning, о котором мы писали совсем недавно.

В качестве исходных параметров утилита принимает файлы упакованных приложений в формате .ppkg, а также специальный файл unattend.xml как часть процесса развертывания Dell Provisioning.

Основные возможности Workspace ONE Provisioning Tool:

• Простой интерфейс, позволяющий администратору валидировать работоспособность файлов ppkg и unattend.xml по аналогии с тем, как это происходит в Dell factory.
• Поддержка пакетов PPKG и unattend.xmls, сгенерированных в Workspace ONE UEM Console 1811 или более поздней версии.
• Гибкость - например, можно в текстовом файле указывать параметры конфигурации утилиты, такие как таймаут операций или размещение отчета о работе.
• Генерация детального суммарного отчета с данными о клиентском окружении и результатами установки приложений. Он сохраняется в C:\ProgramData\Airwatch\UnifiedAgent\Logs\PPKGFinalSummary.log после нажатия кнопки "Apply Full Process".
• Приостановка процесса, если какой-либо из шагов завершился неудачно, что позволяет администраторам найти причину в текущем состоянии приложений и самой машины.
  

Утилита работает в двух режимах:

• Apply Apps Only - установка только приложений на тестовой Windows-машине.
• Apply Full process - установка приложений и применение файлов конфигурации xml на тестовой машине, где исполняется Sysprep и включение ее в среду Workspace ONE (enrollment).

Статус развертывания можно наблюдать в правой панели, а детали будут приведены в отчете:

Скачать VMware Workspace ONE Provisioning Tool можно по этой ссылке.

В конце декабря компания VMware сделала доступной для скачивания новую версию vRealize Network Insight 4.0 (vRNI). Напомним, что о прошлой версии vRNI 3.9 мы писали в сентябре прошлого года вот тут.

vRealize Network Insight предназначен для обеспечения сетевой безопасности виртуальной инфраструктуры, он позволяет системным и сетевым администраторам, а также администраторам информационной безопасности смотреть за сетевым взаимодействием в рамках виртуальной инфраструктуры и предпринимать действия по ее защите.

Давайте посмотрим на некоторое из того, что нового появилось в vRNI 4.0:

1. Поддержка VMware Cloud on AWS.

Новая большая версия vRNI представляет поддержку облачной среды VMware Cloud on AWS (правда пока в режиме Preview). Администраторы могут смотреть метрики для NSX и vCenter, а также потоки IPFIX flows между виртуальными машинами в облаке VMware Cloud on AWS и вашей онпремизной инфраструктурой NSX и vSphere.

vRNI позволяет посмотреть конфигурацию на обеих концах гибридной среды, различные сущности на этом пути, правила сетевых экранов и понять возможные причины проблем:

На этой схеме по клику на компонент можно увидеть облачные виртуальные машины, хосты, настройки сети и безопасности, конфигурацию сетей, VPN-соединения, а также все то же самое на онпремизной стороне. Также на картинке видны маршрутизаторы NSX T0/T1 с примененными к ним правилами фаерволов для путей.

2. Возможность Plan Security и микросегментация.

Для VMware Cloud on AWS можно использовать функцию Plan Security, которая позволяет распознавать паттерны трафика приложений, визуализовывать его и дать исходные данные для его оптимизации с точки зрения приложений.

Все это работает в рамках общего подхода по микросегментации трафика:

3. Возможность просмотра путей VM-to-VM и сущностей Cisco ACI.

Теперь Network Insight может отображать сущности Cisco ACI. Просто укажите vRNI адрес контроллера APIC и вы получите детали конфигурации, такие как фабрика ACI, EPG и их маппинги, Bridge Domains, пути L2 к leaf-узлам, а также схемы VRF для путей ВМ-ВМ.

Помимо этого, для коммутаторов и APIC поддерживаются метрики на базе SNMP. На каждый из элементов фабрики можно нажать, чтобы посмотреть дополнительную информацию (показан дэшборд для фабрики Leaf and Spine):

Индивидуальные дэшборды доступны для следующих объектов:

• Leaf and Spine fabric
• Switches
• EPG
• Application profile

Также для сущностей ACI доступен мощный поиск, который позволяет добавить результаты на pinboard и к ним привязать алармы, если это необходимо.

4. Детали фаерволов Cisco ASA.

Для ASA поддержка со стороны vRNI включает в себя видимость контекста безопасности (security context), прав доступа, групп доступа, сетевых и сервисных объектов или групп, обнаружение и изменение событий, а также правил фаервола в рамках пути VM-to-VM.

На картинке ниже показано представление для VRF на фаерволе ASA с таблицами маршрутизации и другими деталями интерфейсов маршрутизаторов (они показываются для конкретного пути VM-to-VM):

5. Динамические и статические пороги для собираемых метрик (thresholds).

vRNI позволяет добавлять статические пороги для метрик (аларм срабатывает, когда значение больше указанного в течение какого-то времени) и динамические (когда значение отклоняется от предыдущего на определенное значение, например, произошло изменение паттерна трафика):

6. Обновленный NSX-T datasource.

Теперь для NSX-T можно получать такую информацию, как проблемы связности между компонентами NSX, число вызовов NSX API, количество packet drops, flow count, network rate и byte count. Эти метрики доступны для логических коммутаторов и портов, интерфейсов маршрутизаторов и правил фаерволов.

Также поддерживается и NAT с возможностью просмотра правил SNAT, DNAT и Reflexive (stateless). Здесь можно увидеть оригинальные и транслируемые IP-адреса, сервисное соединение, а также входные и выходные интерфейсы:

Также теперь на пинбордах можно искать какие-либо элементы, а также назначать пинборд домашней страницей приложения.

Полный список новых возможностей vRealize Network Insight 4.0 доступен в Release Notes.

Попробовать VMware vRNI можно также как облачный сервис VMware Cloud Service по этой ссылке. Для онпремизных инсталляций поддерживается прямое обновление с версий vRNI 3.8 и 3.9.

Недавно компания VMware сделала доступной онлайн интересную утилиту - VMware Configuration Maximums Tool. Она позволяет быстро и просто найти максимальные параметры конфигураций для различных продуктов VMware:

На данный момент поддерживаются решения NSX Data Center for vSphere, vSphere (правда пока еще нет vSphere 6.7 Update 1), VMware NSX-T, vRealize Operations Manager и VMware Site Recovery Manager, но, скорее всего, этот список будет быстро пополняться.

Помимо продукта VMware и его версии, можно также выбрать и категории максимумов, которые хочется посмотреть (хосты ESXi, виртуальные машины и т.п.). Также полученные результаты можно экспортировать в PDF.

Если в верхней части страницы перейти на вкладку Compare Limits, то мы увидим функционал сравнения максимумов в различных версиях продуктов. Например, выберем слева VMware vSphere 6.7 и сравним с ней две предыдущих версии платформы - vSphere 6.5 Update 1 и vSphere 6.5:

Результаты будут приведены в таблице (обратите внимание, что их можно экспортировать в CSV):

В общем, полезная штука - пользуйтесь.

Сегодня Алексей расскажет про две тонкости с которыми пришлось повозиться на следующем этапе установки – обе относятся к подготовке образа для установки.

Первая – выбор места для установки. Если в вашем сервере на момент загрузки присутствует один диск, и вы планируете его использовать для установки, то проблем нет. А если их несколько, и вам нужно использовать какой-то определенный, то придется указать на желаемый диск с помощью команды:

install --disk=diskname или install –-firstdisk=disk-type

что и прекрасно описано в документации здесь: https://kb.vmware.com/s/article/2004582.

В моем же случае в системе имелся маленький SSD (так называемый BOSS card, в случае Dell – RAID1 массив из двух SATA m.2 SSD) для установки системы и большой RAID-массив, на котором теоретически могли располагаться виртуальные машины (в случае если производится переустановка хоста).

Что в вышеприведенной статье не упомянуто – так это как найти diskname или disk-type для искомого диска/массива.
А сделать это можно следующим образом:

• Проведите тестовую установку в ручном режиме.
• Запустите SSH сервис и подключитесь к серверу по SSH.
• Используйте команду esxcli storage core device list для того, чтобы получить список всех контроллеров в системе.

Искомая информация для вашего контроллера будет в поле Model:

Итоговая команда в моем случае:

install --firstdisk="DELLBOSS VD" --overwritevmfs --novmfsondisk

Вторая тонкость выяснилась, когда я начал тестировать загрузочный диск. Сервер из другой поставки наотрез игнорировал содержимое kickstart файла. Выяснилось что один из серверов был сконфигурирован использовать EFI для загрузки, другой же - классический BIOS. ISO-образ ESXi содержит два различных BOOT.CFG файла для этих двух типов загрузки:

• для BIOS - в корне образа
• для EFI - соответственно, в папке /EFI/BOOT

Если в вашем случае, как и мне, нужно иметь один kickstart файл для обоих типов загрузки, не забудьте отредактировать оба файла.

Надеюсь, это сэкономит кому-то время.

В конце декабря ушедшего года компания VMware выпустила обновление своего консольного фреймворка для управления виртуальной инфраструктурой - PowerCLI 11.1.0. Напомним, что прошлая мажорная версия (PowerCLI 11.0) была выпущена в октябре прошлого года.

Давайте посмотрим, что нового в этом обновлении:

1. Улучшения Site Recovery Manager Module.

Теперь средствами модуля VMware.VimAutomation.SRM для PowerCLI обеспечивается мультиплатформенная поддержка в плане управления инфраструктурой Site Recovery Manager. Этот модуль можно использовать с PowerShell Core на платформах MacOS и Linux. Он стал одним из первых специализированных модулей, сконвертированных на другие платформы.

Также теперь поддерживается последняя версия Site Recovery Manager 8.1.

2. Обновления Storage Module.

В модуле Storage (VMware.VimAutomation.Storage) было сделано несколько исправлений ошибок и улучшений. Теперь командлет Get-VsanDisk выводит диск vSAN, где находится Witness Component. Также для командлета Start-SpbmReplicationTestFailover больше не нужен параметр VvolId.

Скачать PowerCLI 11.1 можно по этой ссылке. Напомним, что традиционно PowerCLI обновляется следующей командой:

Update-Module -Name VMware.PowerCLI

В прошлом году мы писали о выпуске обновленной версии решения VMware Horizon 7.7, а также о его компонентах - VMware App Volumes 2.15 и VMware User Environment Manager 9.6, а сегодня расскажем о последнем из важных компонентов для создания инфраструктуры виртуальных ПК - новой версии VMware Unified Access Gateway 3.4.

VMware UAG представляет собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon.

Напомним, что о прошлой версии Unified Access Gateway 3.3 мы писали вот тут.

Давайте посмотрим, что нового появилось в UAG 3.4:

1. Обеспечение собственной высокой доступности (High Availability).

Как и другие компоненты инфраструктуры VDI, решение UAG теперь поддерживает механизм обеспечения собственной высокой доступности.

Делается это средствами виртуального IP-адреса и Group ID, что позволяет балансировать трафик на порту 443 для более чем 10 тысяч одновременных подключений. Это позволяет снизить операционные затраты на обслуживание таких сервисов, как VMware Horizon 7, Web Reverse Proxy, Per-App Tunnel и VMware Content Gateway.

2. Механизм мониторинга Session Statistic Monitoring для оконечных сервисов.

Теперь с помощью этих функций в административной консоли UAG можно в реальном времени наблюдать за статистиками активных и неактивных сессий, неудачными попытками входа, сессиями протоколов Blast и PCoIP, туннелями и прочими параметрами. Это позволит грамотнее планировать балансировку пользовательских сессий.

3. Режим Cascade Mode для поддержки Horizon 7.

Для организаций, где требуется использование двухслойного DMZ, сервер UAG может работать в каскадном режиме (Cascade Mode). В этом случае внешний сервер UAG работает как Web Reverse Proxy для интернет-соединений пользователей, а внутренний - как Horizon Edge Service.

4. Ограничение доступа к службам Amazon Web Services.

Теперь с помощью UAG можно лимитировать доступ к облачным ресурсам AWS в целях разграничения доступа. В этом случае Unified Access Gateway можно импортировать в облако Amazon EC2, зарегистрировать как Amazon Image Machine (AMI) и развернуть с помощью сценария PowerShell.

5. Поддержка custom thumbprints.

Custom thumbprints позволяют использовать разные сертификаты для соединений Blast TCP и VMware Tunnel. Это можно сделать в консоли UAG или через PowerShell INI.

6. Нативная поддержка Horizon 7.

В консоли Horizon Administrator в дэшборде System Health теперь отображаются детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

Скачать VMware Unified Access Gateway 3.4 можно по этой ссылке.

Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

Цепочка прохождения пакетов по сетевому стеку гипервизора ESXi через различные уровни называется Network IOChain. Это фреймворк, который позволяет на пути следования данных от виртуальной машины к физическому сетевому адаптеру производить различную модификацию данных и передачу их на следующий уровень.

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

• Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

• Обычный или распределенный виртуальный коммутатор (VSS или VDS).

Основная задача этого уровня - направлять пакеты к нужному порту (аплинку), через которые они достигнут адреса назначения. Он оперирует MAC-адресами источника и назначения, а также определяет, отдавать ли трафик локально (в рамках одного или нескольких виртуальных коммутаторов на хосте), либо перенаправлять его к уровню аплинка хоста ESXi.

Кроме того, на этом уровне настраиваются правила NIC teaming по балансировке пакетов между аплинками, подключенными к данному коммутатору. Ну и на этом уровне можно также настраивать политики шейпинга и безопасности для всего виртуального коммутатора в целом.

• Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

Помимо этого на уровне аплинка работают механизмы буфферизации пакетов при всплесках нагрузки (ring buffers), после чего пакеты передаются на DMA-контроллер, чтобы быть обработанными процессором карты и перенаправлены уже в сеть передачи данных.

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

• Fastpaths – фильтры трафика на уровне ядра ESXi.
• Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
• Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

Ну и напомним, что текущая версия распределенного виртуального коммутатора VDS - это 6.6, об их обновлении мы писали вот тут.

Корпоративные заказчики чаще всего используют целый ряд критичных информационных систем, обслуживающих большое количество пользователей. Чтобы избежать нарушений работоспособности такого решения, организации используют проверенные способы в виде аренды виртуальной инфраструктуры у облачного провайдера, предоставляющего услуги PaaS, или виртуального дата-центра, в основе которого лежит IaaS корпоративного уровня.

В последние годы на рынке облачных вычислений наблюдается бум использования технологии Docker, но корпоративные заказчики не спешат переходить на новинку. В этой статье мы рассмотрим причины такого поведения заказчиков.

Виды виртуализации

Контейнеры и виртуальные машины схожи по своей цели: изолировать приложение и его зависимости в самостоятельный блок, который можно запускать где угодно.

Более того: и контейнеры, и виртуальные машины избавляют от привязки к конкретному физическому оборудованию, что позволяет более эффективно использовать вычислительные ресурсы с точки зрения потребления энергии и экономической эффективности.

Основное различие между контейнерами и виртуальными машинами – в их архитектурном подходе.

Виртуальная машина – программная и/или аппаратная система, эмулирующая аппаратное обеспечение некоторой целевой и исполняющая программы для гостевой платформы на платформе-хозяине (хосте) или виртуализирующая некоторую платформу и создающая на ней среды, изолирующие друг от друга программы и даже операционные системы. Виртуальные машины запускают на физических машинах, используя гипервизор.

Гипервизор представляет собой часть программного или аппаратного обеспечения, позволяющую одновременное, параллельное выполнение нескольких операционных систем на одном и том же физическом компьютере – хосте. Хост предоставляет виртуальным машинам вычислительные ресурсы, легко распределяемые между ними. Так что если одна виртуальная машина выполняет запуск более ресурсоемких приложений, вы можете выделить ей больше вычислительных возможностей, чем другим машинам, работающим на том же хосте.

Виртуальную машину, запускаемую на том же хосте, часто называют гостевой машиной. Гостевая машина содержит приложение и все, что нужно для его запуска (например, системные исполняемые файлы и библиотеки). Она также несет в себе весь аппаратный стек, включая виртуальные сетевые адаптеры, файловое хранилище и центральный процессор, и полноценную гостевую операционную систему. Виртуальная машина ведет себя как отдельный блок со своими собственными выделенными ресурсами. Если смотреть снаружи, мы знаем, что это виртуальная машина, использующая общие ресурсы, предоставленные хостом.

Контейнеры

В отличие от виртуальной машины, обеспечивающей аппаратную виртуализацию, контейнер обеспечивает виртуализацию на уровне операционной системы с помощью абстрагирования пользовательского пространства...Читать статью далее->>